@krHERO To be discussed with the developer team: We can also integrate this script into the build process.

@krHERO To be discussed with the developer team: We can also integrate this script into the build process.

I like the idea to integrate this into the build process.
build.sh could test if sencha and ant are available locally and if not then start the build process using the container.

Small addition starts the build process in the container directly:
docker run --rm -it -v `pwd`:/app --name sencha ghcr.io/bwbohl/sencha-cmd:latest /bin/bash -c "./build.sh testing; exit"

What do you think?

great idea. I thought something similar. Maybe we can use testing as default if no parameter is set? I have done something similar with the password (for local development use) here: https://github.com/Baumann-Digital/baudi-docker/blob/main/build-run-docker.sh

My suggestion would be to not provide this as a shell script but rather add this to the ant build.xml.
Since we already have ant in place I think it'd be beneficial to employ this tool for tying together all the build, test, and run steps.

This also includes current build.sh which we (imho) should get rid off.

My intention was to share my way of working, an this was just some addition to build.sh, but I also think we should try to extent the ant build.xml see #440

I converted this to draft until the ant way is explored. I'm intrested in working on that to make a proposal.

My suggestion would be to not provide this as a shell script but rather add this to the ant build.xml. Since we already have ant in place I think it'd be beneficial to employ this tool for tying together all the build, test, and run steps.

This also includes current build.sh which we (imho) should get rid off.

It is an interesting question which tools we expect developers to use. Benni's Docker image has Ant integrated. It would therefore be possible to develop on the Edirom without having Ant installed locally.

Are we talking about the same? I am talking about Benni‘s Sencha-Image not about his Edirom-Image. So what about a short discussion on this at the next developer’s meeting? Maybe we already have some good Workflows and just have to share or combine them?

I was talking about the Sencha-CMD image, too. There is Ant integrated. So technically you don't need Ant locally installed to build Edirom Online.

Are we talking about the same? I am talking about Benni‘s Sencha-Image not about his Edirom-Image. So what about a short discussion on this at the next developer’s meeting? Maybe we already have some good Workflows and just have to share or combine them?

I was talking about the Sencha-CMD image, too. There is Ant integrated. So technically you don't need Ant locally installed to build Edirom Online.

Now, I got it. I guess this is why my first proposal was to integrate the docker commands into build.sh

@krHERO To be discussed with the developer team: We can also integrate this script into the build process.

I like the idea to integrate this into the build process. build.sh could test if sencha and ant are available locally and if not then start the build process using the container.

Small addition starts the build process in the container directly: docker run --rm -it -v pwd:/app --name sencha ghcr.io/bwbohl/sencha-cmd:latest /bin/bash -c "./build.sh testing; exit"

What do you think?

@riedde, if you follow Daniel's suggestion, the docker command can't be integrated into build.sh because build.sh is called inside the docker container. So you would need another shell script for calling docker.

Thanks for the hint! I'm going to investigate some solutions and present them at the next meeting.

Proposing small change to current script

• flag "-d" starts docker container and in there the script is executed in the former way

Tested on my machine. Works fine! Thank you @daniel-jettka for your help!

@riedde please do not hit the "update branch" button and merge dev into this branch. This will create "ugly" history for it inserts all those unnecessary merge commits. It's better to rebase the branch but beware that you'll need to eventually reset hard your local clone.

@peterstadler Okay, I won't use this button again, but rebasing is not my favourit way of working. It cost a lot of time because there are always conflicts that are mostly hard to handle. Especially when there is to much code formatting.

@daniel-jettka could you have a look at the code suggestions and whether this works for you?

@daniel-jettka could you have a look at the code suggestions and whether this works for you?

see above :-)

@peterstadler @riedde What do you think, can this be merged now?

The code is great now but yet another PR with several unnecessary and history polluting merges …

@peterstadler Could you bring this up at the next community meeting? I think everyone is doing update, rebase and merge in his/her own style at the moment.